Skip to main content

How is it done?

TODO - THIS NEEDS MUCH MORE WORK. CURRENT THOUGHTS ARE TOO VERBOSE. I’M CURRENTLY DESCRIBING THE INITIATION STAGE OF A LARGE SCALE PIECE OF WORK. MAYBE SOMETHING THAT JUST TOUCHES ON 1) INITIAL REQUIREMENT, 2) INITIAL DESIGN, 3) LOWER LEVEL REQUIREMENTS, 4) MID LEVEL DESIGN.

How and when Solution Architects are engaged varies according to the perceived complexity of the problem. In many cases at the outset of a change there’s a view on scale. Government legislative change that touches multiple teams and business processes requires an approach very different from expected localised change in a single system.

If we take the case of a non trivial large scale change it could take the form of:

  • The idea. A business need is established. Legislative change, improve an existing process, introduce a new product or service. There’s likely a high level sense of the roles to fill and the fact there will be a technology element to any solution. That’s why you’ve got an early seat at the table.
  • Initiation - Some structure is formed around the what, why and who. Often this will be getting representatives from various core domains together with the objective of sharing what is understood about the problem. Business stakeholders, project/programme management, analysis, technology.
  • Workshops - Representatives from various domains come together to draw out high level areas of focus. Business Analysis resource may lead these sessions. A common output being a list of Agile epics which break the problem into defined categories
  • Provisional design - It should be possible at this stage to identify the capabilities needed. E.g. payment processing, case management etc. Previously defined epics usually map well towards these capabilities. These capabilities can be further refined by a Solution Architect into provisional functions needed. E.g. setup new payment, receive payment, monitor payment, cancel payment etc. Each organisation will typically have strategically approved components which serve such functions. These components and their interactions allow an Architect to daw out a high level view of the systems involved.